home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970929-19971216 / 000046_news@newsmaster….columbia.edu _Sat Oct 4 12:17:12 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id MAA10354
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Sat, 4 Oct 1997 12:17:12 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id MAA29118
  7.     for kermit.misc@watsun; Sat, 4 Oct 1997 12:17:11 -0400 (EDT)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.protocols.kermit.misc,comp.os.linux.misc
  11. Subject: Re: 2 queries
  12. Date: 4 Oct 1997 16:17:10 GMT
  13. Organization: Columbia University
  14. Lines: 86
  15. Message-ID: <615q66$sft$1@apakabar.cc.columbia.edu>
  16. References: <34325162.42877E5C@rss.rockwell.com>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:7814 comp.os.linux.misc:218226
  19.  
  20. In article <34325162.42877E5C@rss.rockwell.com>,
  21. Ian Diddams  <ian.diddams@rss.rockwell.com> wrote:
  22. : 1) Is there an archive of comp.protocols.kermit.misc anywhere that you
  23. : know of:
  24. : 
  25. ftp://kermit.columbia.edu/kermit/newsgroup/misc.*
  26.  
  27. : 2) I can use kermit fine on my linux box (usr robotics 14400 internal)
  28. : but after dialling, connecting, doing, exiting....  I return to kermit,
  29. : but on exiting I get a message regarding "serial connections may still
  30. : be open".
  31. : I can't find a command to "clear" this staus, but if I exit anyway, next
  32. : time I try to use kermit, it "hangs" trying to set line /dev/ttyS1;
  33. : there's nothing obvious in /var/lock.
  34. : What am I doing wrong?
  35. : 
  36. Ian and I worked this one out over the past few days while his posting was
  37. in transit.  We now have the following entries from Ian and others in the
  38. working copy of the C-Kermit for UNIX "beware file" (ckuker.bwr):
  39.  
  40. "set line /dev/modem" or "set line /dev/ttyS2", etc, results in an error,
  41. "/dev/modem is not a tty".  Cause unknown, but obviously a driver issue, not a
  42. Kermit one (Kermit uses "isatty()" to check that the device is a tty, so it
  43. knows it will be able to issue all the tty-related ioctl's on it, like setting
  44. the speed & flow control).  Try a different name (i.e. driver) for the same
  45. port, e.g.  "set line /dev/cua2" or whatever.
  46.  
  47. "set modem type xxx" (where xxx is the name of a modem) followed by
  48. "set line /dev/modem" or "set line /dev/ttyS2", etc, hangs (but can be
  49. interrupted with Ctrl-C).  Experimentation shows that if the modem is
  50. configured to always assert carrier (&C0) the same command does not hang.
  51. Again, a driver issue.  Use /dev/cua2 (or whatever) instead.
  52.  
  53. More on the ttyS0 vs cua0 issue (quoting from a user, October 1997):
  54.  
  55. Platform: Intel 486 PC, Caldera Open Linux (Base), USR Robotics 14400 
  56. internal modem.
  57.   
  58. Problem: When using C-Kermit with a ttyS? device, the modem works fine the
  59. first time a modem connection is attempted.  Upon exiting kermit, the message:
  60. "A serial connection might still be active on /dev/cua1.  OK to exit?" is
  61. displayed.
  62.  
  63. Answering "yes" at this point seems to hang the line up, such that the next
  64. time C-Kermit is run on that device, it will not open the line - C-Kermit just
  65. sits there until the user breaks (control-C).  Nothing within C-Kermit appears
  66. to rectify this situation - the same question is asked with the same
  67. consequences whatever attempts are made to "clear" the line.
  68.  
  69. The workstation must then be rebooted.
  70.  
  71. Fix: Although the Linux implementation may not necessarily indicate that it is
  72. available, the cua? device is available as an alternative to the ttyS?; e.g.
  73. /dev/cua0 works as well as /dev/ttyS0.
  74.  
  75. Use this /dev/cua? device instead of the ttyS? one, and although the same
  76. message might be displayed on exit, the consequences do not occur; i.e. the
  77. line is available again next time C-Kermit is used ...  and without rebooting
  78. the workstation.
  79.  
  80. Reasons: ????  See Linux documentation with your distribution if there is any,
  81. otherwise Linux documentation is available on the WWW.
  82.  
  83. (end quote)
  84.  
  85. from /usr/doc/faq/howto/Serial-HOWTO
  86.   12.4. What's The Real Difference Between The /dev/cuaN And /dev/ttySN
  87.         Devices?
  88.   The only difference is the way that the devices are opened.  The
  89.   dialin devices /dev/ttySN are opened in blocking mode, until CD is
  90.   asserted (ie someone connects).  So, when someone wants to use the
  91.   /dev/cuaN device, there is no conflict with a program watching the
  92.   /dev/ttySN device (unless someone is connected of course).
  93.   The multiple /dev entries, allow operation of the same physical device
  94.   with different operating characteristics.  It also allows standard
  95.   getty programs to coexist with any other serial program, without the
  96.   getty being retrofitted with locking of some sort.  It's especially
  97.   useful since standard Unix kernel file locking, and UUCP locking are
  98.   both advisory and not mandatory.
  99.  
  100. The best advice about using /dev/ttySx in C-Kermit seems to be, like the
  101. doctor says, "if it hurts, don't do it".
  102.  
  103. If any Linux experts would care to shed further light on this, please do!
  104.  
  105. - Frank